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navigation APIs may Indude flow 132 and operation 133 APIs. These flow and operation APIs preferably 
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paneCname^^lN MENLT 

destpaneliname^^lnventor/'^d jstance="1 " 
input1ie(dname=''Option'', valuo«*l* 
executekey:name»'*Ent8i* 
enddestpanei 

destpanetnames'Work with Orders", distanc8«"1" 
inputfiddname="Option",value=^ 
executelc^nafneB"EntBr 

enddestpanei 

destpandiname^TurchasIng*. distance«"r 
input:f!eldnaine«"Option".value=^ 
executekey:names'^nter^ 

enddestpanei 

destpanel:name=Xustomefs-, dlstance=M" 
inputfieldname=-Option",value«*4" 
executekey:names''Enter^ 

enddestpanei 

destpane!:name»*^ider Processing", dtstance"^** 
lnput:fie!dname='*Option",value5="2'' 
executekey:name='*Entef^ 

enddestpanei 

destpanefcname«"OnJer Enny . dbtance="3* 
input:fieldname=-Option",value«*2" 
execirtekey:nanie='*Entei'* 

enddestpanei 

destpanel:name='*Customer Data", distance^*^ 
inputfieldname=-Optton",value="4" 
executekey:riame«"Entei^ 

enddestpanei 
endpanet 
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panel:name="Woric with Orders" 

destpanel:naiTie=^lnquiry",distanc8='*1" 

inputfieldname«"bt5tion", ysdue^V 
executekey:name»%nter^ 
enddestpanei 

destpanel:nanies''0rd6r Processffig^ dtstance»"1" 
inputfieldname^O|>tion'',value>=*'2" 
executekey:name»''Enter 

enddestpanei 

destpanel:name="Reports", distance^'^l" 
input:fieIdname="Option*'»values'*3'! 
executek^.name«'^ter^ 

enddestpanei 

destpanel:name«Tile Maintenance*', dislance^r 
input:fieldname=*'Optlon",vafue^M* 
exectitekeyrnameas^Enter* 

enddestpanei 

destpanel:name=^Cu8tomers^ distance^r 
lnput:fieWname="Option",value«^y 
executekey:name^Enter" 

enddestpanei 

destpanel:name="MAlN MENU", distance^T 

executelcey:names"F1 2" 
enddestpanei 

destpanel:name="Order Entiy" , distances*^" 
lnputfieldname«"Oplion",value=Y 
executekey:name^^ter" 

enddestpanei 

destpanel:name-"Customer Data'', d^nces"2" 
lnputfieldname^''Option",valije="5* 
executekeyinamea'^ter^ 

enddestpanei 

destpanel:name»-lnventoiy"t distance*^ 

executekey:name=:"F1 2" 
enddestpanei 
endpanei 
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panel:name='*Order Processing*' 

destpdnei:name=-Order Entr/*,distance=»"r 
inputfieidriame»"Opfion", vakie^l" 
executekey:nafne«^Enter^ 
enddestpanel 

des^aneirname-Trint Order Documente". distance^''1" 
inputfieldnaine»*Option''.value='^* 
execut6key:name='**Enter" 

enddestpanei 

destpaneirnames^Shipping Documents", distanc6s'*1'* 
inputfieidnames'*Opt{on^values"3* 
executekeytnames^Entei^ 

enddestpanei 

destpanel:name»**Systeni Suppoif. cBst^cea^r 
inputfieldname="Option",value="4* 
executekeyiname-^Entei* 

enddestpanei 

destpanei:name="MAIN MENU^ distance^^r 

executekey:name=»^F3* 
enddestpanei 

destpanel:name-"Work with Orders", dis&nces^l'' 

executekey:nan)e«"F1 T 
enddestpanei 

des43anel:name»^stomers". distances^"* 

exe«Jtekey:narne=T3" 
enddestpanei 

destpanelrname^CustDmer Data". distanc^^S" 

executekey:name=s"F1 2* 
enddestpanei 

destpanei:name='1nventory", drstance*"!" 

executekey:name="F4" 
enddestpanei 
endpanei 
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panelrname^^Order Entiy" 

destpanetname^Add Ofdar^,cSstaiioe=s''1 * 
inputfietdnames''Option''. value^l" 
putitern:ciientfieldname»"OrdefNumber^. 

app6cationfietdname="OrderNbr" 
executekey:nanie=='^ter" 
enddestpanel 

destpanel:ndmea"Change Order^, distance^l"* 
inputfietdnames'OpttHi'.values^ 
putHaemrcUentfieidname^'XMtfNumbe^ 
appOcab'onfieldname^^OfdefNbr* 
executekeyuiame='*Entei^ 

enddestpanel 

destpanetnames=T)isplay Ofdei*, dtstance^^r 
inpuLfieklnam6s"Option*.vaiues*'3*' 
putltem:c{ientfieidname<»*OrderNunibef^. 

applicationfieldiiame=''*OrderNbi^ 
executekey:name»*'Entef^ 

enddestpanel 

destpanel:name^elete Order^, dislanoGs"1" 
jnput:fieWname=-Option",value=M* 
putltem:citentfieidnamee''OrderNuiTibei^, 
appfoationfie}dnames''OntefNbr^ 
executekeytnameA^Entef* 

enddestpanel 

destpaneiiname^MAIN MENU^ distance"*^" 

executekey:naniev*F3'' 
enddestpanel 

destpanei:name='Worfc with 0^ders^ distance^'?'' 

executekey:nafne^F12* 
enddestpanel 

destpanel:name='*Order Processing"* distance^^r 

executekey:nanie="F12** 
enddestpanel 

destpanebnames^Customeis", distanoea^** 

executekey:name»''F3*' 
enddestpanel 

destpanet:name="Custoiner Data", distance^'' 

executekeymame="F3* 
enddestpanel 

destpanetname^'inventory*. dlstance=*2" 

executekey:name^l2* 
enddestpanel 
endpanel 

FIG. 12 
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paneknan^Ojstamers" 

destpanel:name«''Add Customer Data", distance«"1" 

inputfie}dnaine="Option",value="1" 

puUtem:dientfieklnames"cu$ttD^applicatior!fiekJnames''c^^^ 

executekey:namea"Enter" 
enddestpanel 

destpanei:name«'Edit Customer Data", distance^s'l" 
input1leidname»^Option*,vsdue3^ 
pumem:c6entfiekinames"eustlD",applicattonfieidnames 
executekey:namess"Eirtef* 

enddestpanel 

destpanel:names"CustomerOala", distance"^" 
lnputfieldname'="Option",vaJue*"3'' 

putltem:dientfieUtaames"cusaD",appficatlonfieWname3-caistomerlD" 
executekey:name=" Enter* 
enddestpanel 

destpanel:names"Delete Customer Data", distance="1'' 

input:fieldnamea^ption".valuea"4" 

putltem:ciientfieldname*<"aisdD",applicationfieldnan^ 

executeicey:nam^Enter" 
enddestpanel 
if lastpanel:names"MAlN MENU" then: 

destpaneCname^MAlN MENU". distance«"1" 

executekey:names"F12" 
enddestpanel 

destpanel:name=lWofic with Orders". dlstance«"2" 

executekeyjiaine=T12" 
enddestpanel 

destpanel:name»"Order Processing", di s taii c e c "3" 

e)(ecutekey:name3T12" 
enddes^anel 

destpanel:name::"Order Entry", distanc6="4'' 

executekey:namesn2" 
enddes^anei 

des]panel:names''tnventory". distance«"2" 

executekey:name>«"F12" 
enddestpanel 
else /'lastpanel:name«n/Voricwith Oideis" V 
(SEE FIG. 14) 

FIG. 13 
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(CONTINUED FROM FIG. 13) 

destpanet:name=''MAlN MENlT^distance^-'T 

executekey:name«''F12* 
enddestpanel 

destpanel:name=^ork with Orders", dbtance="1" 

executekey:name==:**F12*' 
enddestpanel 

destpanelrname^Order Processing", distances*?* 

executekey:name»"F12'' 
enddestpanel 

destpanetname^'Order Entiy", distanced" 

executekey:nameeT12" 
enddestpanel 

destpanel:name«>*CiJStomer Data". distance»"r 
input:fieIdname=!"Optton",value«"3" 
executekey:names''Enter" 

enddestpanel 

destpanel:name=^"1nventory", dlstance="3- 

executekeyjianie="F12" 
enddestpanel 
endpanel 
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panei:name-'*Customer Data" 

destpanel:name»miN MENU^ distance»^"1'' 

executekey:name55"F3" 
enddestpanel 

destpand:name='Work with Orders", distance«"2" 

executekey:name«^F3* 
enddestpanel 

destpanehnames^Order Proces^ng^, distance^S"* 

execut0key:name«"F3'' 
enddestpand 

destpanel:name="Ofdar Entry", dtetame^'M*' 

executekey:name=^F3* 
enddestpanel 

destpanel:name="Customers-, distance^T 

executekey:name='T12'' 
enddestpanel 

destpane!:names=nnventor/, dfetance^ 

executekey:name="F3- 
enddestpanel 
endpanei 
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panel:name=*lnventofy* 

destpanelrname^^-Physical lnventor/',dlstance«"1* 

inputfieldname="Option", value="1* 

executekey:names*^ter^ 
enddestpanet 

destpandrnamesTleports*, dfetance="1- 
input:feldnainesX)ption^values^ 
executekeyntames^Enter* 

enddestpanet 

destpanel:name="Ordef Processing**. distance=^1" 
input:fieklname'^OptioR'*,value»*3* 
execufekey:name=>"Ent8f* 

enddestpanel 

destpanel:name="Utility"» dlstance="1" 
inputfieldnafne=:'*Option",value="4* 
executekeyrname^^'Enter* 

enddestpanel 

destpaneJ;name="Systeni SupporT, di8taoce»-1'* 
inputfieidname*"Optlon",value«*5" 
executekeyrnanies^Entar' 

enddestpaneJ 

destpanel:nanie«*MAIN MENIT, distance»*r 

executekey:name="F12* 
enddestpanel 

destpanel:name="Woric with Orders", distances'^ 

executekey:nanne«*F1 Z* 
enddestpanel 

destpanel:name»"Order Entry, distance==^ 
input:fieldname«''Option",value«^* 
executek0y:nanne«^En1er" 

enddes^anel 

destpaneJ:nafne«"Custoni©rs", distances^" 

executekeytnames^FI 2"* 
enddestpanel 

destpanel:name^'Custon>er Data^ dlstance="3" 

executekey:nanne="F12" 
enddestpanel 
endpanel 
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MAIN MENU ZHfi 
OperaJion="GET_USERJNFO' 

Option 4. Enter 
Opefation="ORDER_ENTRr' 

Option 2. Enter 
Operation«T)ELETE_ORDER" ^ 



Option 2, Enter 
Operation«CHANGE.OROER 
Option 2. Enter 



Opt2& 
Enter 



Opt 1 ft Enter 



1400 



Opt4 & Enter 



Woric with Orders 220. 
Operation="ORDER.ENTRY" 

Option 2. Enter 
Operation«"DELETE_ORDERr 

Option 2. Enter 
Operation="GET_USERJNFO" 

Option 5. Enter 
Operation="CHANGE_ORDER" 

Option 2, Enter 



F12 



Opt2& 
Enter 



1 



Customers 
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Operation«"GET_USERJNFO" 
*Move custlO to custiO field 
*Set menu option to 3 (display) 
*Exeail8 Enter - 



F12 



Opts & 
Enter 



Order Processing Z2& 

Operation="ORDER_ENTRY" 

Option 1, Enter 
Operation«"DELETE_OIRDER" 

Option 1, Enter 
Operation*"CHANGE.ORDER" 

Option 2. Enter 



SL 



Opt3& 
Enter 



! 



F12 



Customer Data Z§fi 
Operation="GET_USERJNFO" 
*Move field custName to Name 
-J *Move Field custAdrto Address 
^ -Move field custClty to City r 
•etc 

•ExecuteF3 16 return to PO 




Order Entry 



Operations'ORDER.ENTRY" 

Option 1, Enter 
Operallon«"DELETEjORDH%" 

Option 4, Enter 
Operation="CHAN6E_0RDER" 

Option 2, Enter 




FIG. 17 
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paneknamea'MAIN MENU" 

operation:name«^ET_USER_INFO' 

input:fieidnames"0ptk3n*. values^" 
executei(ey:nameB"BTtei' 
endoperation 
endpanel 



panei:name=''Customefs*' 

operation:name=s^ET_USERJNFO* 

rSet the customer number on ttie application's screen and hit enter*/ 
putltem;ciientfieldname»"custlD",applteatlonfieidname»"customeriD" 
input:rame='*0ption",value«*3" 

• executekeytname^Enter" 

endoperation 



panel:name="Customer Data" 

operation:name="Ger_USERJNFO" 

rRead the customer data and send to dient*/ 

getItem:applicationfieldname="custname",cllentfieldname's"name" 

getttem:appDcat'onfieldname^custadr1*,dientfieidname=''addressr 

getltem:applicationfieldnarne«>"cu8bdi2".clientfieidnanr)ee*addres^ 

getttem:applicationfieldnanrte="custcjty".cllentfieldnarne="city" 

getltem:appricat]onfietdname«^cuslstsM''.dientfi^nante»^te*' 

getiten):appncationfieidnan)e-^".client(ieidnames^'' 

getlteni:appricationneldnarnes^cus^hone*,clientfieldnarne^hon6" 

y*Move back to the niain menu*/ 
executekey:najn^''F3'' 
mdoperatkNi 




endpanel 




endpanel 
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1 

catspmzsi systsm tbat dsfzmbs KxviGkTZQir of a 
sorrmRE applxcatzok 

This invention generally relates to computer systems, and more 
specifically relates to data processing in computer systems using a 
graphical user interface (GUI) . 

Since the dawn of the conqputer age, cong^uter systems have evolved 
into extremely sophisticated devices, and computer systems may be found in 
many different settings. In the early days of coo^^uters, one or more 
relatively powerful and expensive cosnputers could be shared by many users. 
A network of con^uter terminals were typically connected to a single 
computer known as a ^^host," These cooqputer terminals are commonly known as 
non-programmable workstations (i.e.^ **duinb terminals'' ) because they siaiply 
display information transmitted to it by the host, and lack axty processing 
power to perform local tasks. One example of a very well-known coitputer 
terminal is the IBM 5250, which displays alphanumeric text in row and 
column format. In a computing environment with a host and one or more 
terminals, software applications run on the host, and display information 
is transmitt.ed by the host to the terminals, ndiich displays an appropriate 
screen to the user. The user may then enter data in response to the 
displayed screen, if required, software applications that ran on these 
types of systems are known as *host -based'' software applications. These 
are commonly referred to in the computer industry as ''green screen" 
applications, taking their name from the green color of maxxy of the dumb 
terminals used to interact with these applications « 

Green screen applications typically display information in a 
text •only format of rows and columns on a termi na l or conoputer screen. 
More modern advances in user interfaces have resulted in a variety of 
Graphical User Interfaces (GUIs) that allow a user to interact with the 
coinputer using a pointing device such as a mouse » A GUI is typically much 
easier for a -user to use compared ^g^j green screen^interf ace • Popular 
browsers, such as Netscape Navigator^or Microsoft ^Internet Explorer, 
include a GUI that accesses and displays information from the world-wide 
web. A GUI may provide windows, drc^^down lists, context-sensitive help, 
etc., all at the click of a button. Another example of a GUI is the OS/2^ 
operating system developed and sold by IBM. As users become more familiar 
with GUI. concepts, entering data into an ""old fashioned" green screen 
application seems less intuitive and training is more tedious. However, 



converting all green screen applications to include a GUI would be a 
formidable and e9^ensive undertaking » 

Many green screen applications Jiave been developed for a variety ot 
different industries and companies at great expense « To completely 
re«%frite a green screen application to provide a GUI would take 
considerable time and resources. Not only would it be time-consuming and 
expensive to re-write a green screen application, but it also would 
essentially throw away imich of the benefit of having stable, solid code 
that has been debugged and operating correctly for sooae period of time. A 
re -write would undoubtedly produce a host of new bugs that would have to be 
corrected. Thus, what is needed is a way to provide a GUI front -end on a 
green screen application to avoid re- writing the underlying logic that is 
cried and true. 

One known solution that provides a GUI for green screen applications 
is known as ^'screen scraping. With a screen scraping approach^ the 
underlying code of the green screen application is not affected. It still 
puts and gets data in data streasns just as it always did. Screen scraping 
provides software that cakes the screen information and compares the screen 
infonnation against a table or other database of possible screens for the 
particular application. Once the screen information is correlated to a 
known screen, the screen scraping software knows what information needs to 
be displayed, and can map that Information to a GUI. Screen scraping 
typically employs one or more processes that contintially run to provide the 
translation between green screen fon&at and QUI format. This translation 
typically requires detecting the screen to be displayed and then displaying 
the corresponding GUI screen* 

With the introduction of the personal computer (PC) , networks for 
personal computers were developed that allow computers to intercoimmmicate . 

Thus, instead of providing a host -based system of the past, the personal 
computer made it possible to have a network of powerfixl workstations rather 
than dumb terminals. The processing power of a workstation makes it 
possible to share processing between computers on a network^ rather than 
having all the processing performed by a host computer. Thus emerged a new 
paradigm known as client/server coa^uting» or network computing* %^ch 
allows computer workstations known as clients to interact with one or more 
server coniputers. 

Migrating green screen applications that were developed for a 
host -based system into the client/server environment is relatively 
straightforward. The easiest way is for the comoputer workstations to 



emulate a duinb terminal « While this approach does not take advantage of 
the processing power of the client workstations, it does allow green screen 
applications to be implemented in a network computing emrironment with a 
minimum of effort. However « as described above « users in a network 
computing environment are becoming more accustomed to GUIs for their 
applications^ and would prefer to interact with green screen applications 
using a GUI. 

Known screen scraping techniques require a programmer to 
custom-program a GUI to each green screen s^lication by calling low- level 
fxmctlons that interact with the green screen application. The programmer 
must have detailed knowledge of the application and the GDI* and create 
code that bridges the gap between the two by defining the navigation of the 
green screen application for the GUI. Without a way to define navigation 
of a software application without custom-programming a GUI, the cocrqgiuter 
industry will continue to suffer from excessive development costs when 
creating a GUI for a green screen application. 

According to the present invention there is provided a computer 
system comprisdLng: 

at least one processor; 

a memory coupled to the at least one processor; 

a navigation tool residing in the memory for execution by the at 
least one processor, the navigation tool receiving flow definitira for a 
software application from a user and generating therefrom at least one 
application program interface (API) for navigating the softwasre 
application. 



In an embodiment o£ Che invention, a navigation tool is used to 
define the flow and operation of a host -based application. The navigation 
tool generates from the flow and operation information navigation APIs that 
allow a GDI to communicate with the host -based application. In the 
preferred embodiments, these navigation APIs include flow APIs and 
operation APIs. These flow and operation APIs preferably interact with 
pre-existing screen scraping APIs to communicate with the host -based 
application. By defining higher level functions in the flow APIs and 
operation APIs than those available in the screen scraping APIs« the GUI 
way be programmed in a more general and descriptive way that makes porting 
the GUI to a different host-based application much easier to do. The 
navigation tool of the present invention is especially useful for 
web* enabling an existing host-based application. The user enters the 
relevant information from the host -based aj^lication into the navigation 
tool« v^ch then generates navigation APIs for navigating the host -based 
application. Any functions of the host -based application that are not 
entered into the navigation tool will' not have corresponding APIs 
generated, which makes it easy to define v^ch functions will be 
web-enabled (by providing support in the 601) and which functions will not. 

Bmbodiments of the present invention will now be described with 
reference to the accompanying drawings « wherein like designations dexiote 
like elements, and wherein: 

FIG. 1 is a block diagram of an apparatus, in accordance with a 
preferred embodiment of the present invention; 

FIG. 2 is a block diagram of a host computer system running a green 
screen application; 

FIG. 3 is a block diagram of a client/server network running a green 
screen application; 

FIG. 4 is a block diagram of a prior art computer program; 

FIG. 5 is a block diagram of a computer program that includes 
navigatim APIs in accordance with the preferred embodiments of the present 
invention; 

PIG. 6 is a flow diagram of a method for defining navigation of an 
application in accordance with a preferred embodiment of the present 
invention; 
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Vl PIG. 7 is block diagram of one example menu structure for a sawple 

Q green screen application for illustrating* the concepts of the preferred 

eTnbodiment ; 

y FIG* 8 is a block diagram of the display panels shown in FIG. 7 with 

5 notations relating to the navigation of the green screen application; 

FIG. S is ^sample script description of the "Main Menu' panel shown in 
PIG, 7; 

PIG. 10 is sample script description of the ""Work vrith Orders'* panel 
shown in PIG. 7; 

10 PIG, 11 is saniple script description of the "Order teocessing" panel 

shown in PIG. 7; 

FIG. 12 is sample script description of the ''Order Entry* panel shown 
in PIG. 7; 

FIGS. 13 and 14 are a sainple script description of the ^Customers" 
15 panel shown in PIG. 7; 

PIG. 15 is sample script description of the ""Customer Data*' panel 
shown in FIG. 7; 

FIG. 16 is sample script description of the ^inventory" panel shown 
In FIG. 7; 

20 FIG. 17 is a block diagram of the menu structure of FIG. 7 showing 

the definition of operations in accordance with the preferred embodiments ; 

FIG. 18 is a sample script description of a GBT_reER_IHFO operation 
defined in the Main Menu panel of FIG. 7; 

FIG, 19 is a sample script description of a 6ET_USER_INF0 operation 
25 defined in the Customers panel of FIG. 7; and 

FIG. 20 is a sample script description of a GET_OSER_IOTO operation 
defined in the Customer T>ata panel of FIG. 7, 



Referring to FIG. 2. a hcst-based computer syst.em 200 incliidest a dumb 
terminal 210 chat is coupled via terminal connections 225. to a host 
computer 230. Dumb temlnal 210 includes a display screen 220 tot 
displaying information to a user. Host computer 230 includes a green 
screen application 232, Green screen application 232 inclx^es core logic 
240 that contains and/or generates variable display data. 242. Green screen 
application 232 communicates viith terminal 210 through calls 243 to display 
application program interfaces (APIs) 244 • Display APIs 244 typically 
include a POT APX, a' GET API. and a P0TOB7 API. The PUT API outputs 
display informatiOQ to terminal 210 for display on display screen :^20. The 
GET API receives input inEozmation from terminal 21C. The PUTGET API 
outputs display infomiation to terminal 210 £or display .on display screen 
220 r then waits for the user to respond with input infcntation. 

Data is output for display cn terminal 210* by paxsincr. variable 
display dat^. 242 to one of the POT or FUTGfiT APIj: thrcu^ a call 243 co Uic 
appropriate API. The A?l then detennines which display file 2S:> is 
specified. The display file may be specified along with the variaLle 
display data, but more commonly is specified by a separate FORI^T command 
that identifies the appropriate display file 250 before passing the 
variable display data 242 to the PUT or PUTGET API. The information to be 
output to terminal 21? typically includes a variable pprtion/ represented 
by variable display data 242/ combined with 4 fixed pprtion, repre^^ented by 
a corresponding display file 250. The combination of variable and fixed 
data is a screen or a portion of a screen to b^. displayed^ on term^ial 2XU . 

The advene of the PC and computer networhs. for PCs ^%eated 
client/server environments* Referring to FIG, 3, a client/ser';er computer 
system 300 may be used in the place of the host/terminal c<;^aputeir system 
200 Of FIG. 2. Green screen applications fixe easily ported to a 
client /server environment 300 by placing the green screen application 232 . 
in a server computer system 330. The green screen application itself 232, 
disp;Lay APIs 244 and display files 250 remain unchanged, but are now 
executed by a server thc^t serves as a host. Network 170 replaces tei-min^l 
connections 225, and a client workstation 31C replaces dumb terminal 210. 
Client workstation 310 is preferably a computer syscem (such as a PC) that 
can perform local processing as well as communicating vdith. other computer?! 
via network l^o. client wrkscanion 310 typically includas 1 teiroinal 
emulator 312 that makes client workstation 310 appear as a dumb terminal to 
any progran'iS (such as green screen application 240) that format th«^ir 
display Input and output for dumb terminals, ■ -In this manner, * 



client/server environment 300 may be made to emulate the host /terminal 
exnrironment 200 of FIG. 2. 

As stated in the Background section, screen scraping is a knovm 
technique that allows a graphical user interface (GUI) to be defined for a 
green screen applir.ation. One of the principal advantages of screen 
scraping -is that the logic of the green screen application is \mchanged. 
As far as the green screen application is concerned, it is still 
communicating with a dumb terminal* Screen scraping software thus provides 
low- level application program interfaces (APIs) that emulate the dunda 
terminal interface for the green screen application in functic«x calls for a 
graphical user interface* Exaxoples of ]cnown screen scraping software 
include IBM's Enhanced High Level Language Application Program Interface 
(EHLLAPI). and object oriented APIs provided by Jacada, Inc. 

Screen scraping APIs can best be understood with reference to a known 
computer program 400 shown in FIG. 4. A green screen application 125 
represents any software application tiiat is designed to communicate with a 
dumb terminal. Screen scraping APIs 126 (such as those referenced above 
provided by IBM Corp. or Jacada, Inc.) provide low- level functions that 
put to and get data from the green screen application 125. Graphical user 
interface 434 is a GUI that is custom-progranwed to invoke screen scrying 
APIS 126 when data exchange with the green screen application 125 is 
required. GDI 434 typically includes a number of predefined GDI APIs 435 
that can be used along with screen scraping APIs 126 to communicate between 
the green screen application 125 and GUI 434* Screen scraping APIs 126 and 
GUI APIs 435 thus provide a translation mechanism for moving data between 
the green screen application 125 and the GUI 434. Note, however, that the 
graphical user interface 434 must include logic that allows directly 
invoking the screen scraping APIs 126, which requires that GUI 434 have 
detailed knowledge of how the screen scraping APIs 126 interact with green 
screen application 125. The resiilt is a GDI that is custom programmed for 
a single green screen applicationi n^ch cannot be easily ported to a 
different green screen application. 

According to a preferred embodiment of the present innrention, a 
software tool is used to define the navigation of a green screen 
application, and the tool then uses this inforiaatiw to generate navigation 
APIs {e.g., flow APIs and operation APIs) that allow a GUI to invoke these 
APIs to communicate with the green screen application without the GUI 
having any detailed knowledge regarding the green screen application. 
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Referring to FIG* 5, the APIs that are senerated by the software tool 
in accordance with the preferred embodiments aire referred to herein as flow 
APIs 132 and operation APIs 133, which are collectively referred to as 
navigation APIs 131. Note that these APIs constitute "middleware", which 
is used herein to refer co software that is used to conummicate between'*two 
other software programs or program portions. In FIG. 5, the screen 
scraping APIs 126 and green screen application X25 are the same as shown in 
the prior art in FIG. 4. The primary distinction over the prior art is the 
addition of the flow APIs 132 and operation APIs 133, which resxilt in a 
greatly simplified graphical user interface 134 . Flow APIs 132 define 
functions at a higher level than screen scraping APIs 126, such as how the 
navigation of the green screen application is performed. Flow APIs 132 
suitably invoke screen scraping APIs 126 to define these navigation 
functions. Operation APIs 133 define functions at a higher level than flow 
APIs 132. Operation APIs 133 suitably invoke flow APIs 132 to define 
operations that may need to be performed by interacting with the green 
screen application 125. Graphical user interface 134 is thus progranmed by 
calling high level functions defined by flow APIs 132 and ^>eration APIs 
133, instead of dealing with the low- level screen scraping APIs 126 « These 
navigation APIs 131 thus provide high-level flow and operation functions 
that may be invoked by the graphical user interface, which effectively 
removes the need for any information specific to the screen scraping APIs 
126 in developing the graphical user interface 134. Mote that in the 
preferred embodiments, GUI 134 includes a number of GUI APIs 135 that can 
be used to pass data to and from GOI 134. 

Referring to FIG. 1, computer system 100 is an enhanced Tm AS/400 
computer system. However, those skilled in the art will appreciate that 
the mechanisms and apparatus of the present invention apply equally to any 
computer system, regardless of whether the computer system is a complicated 
multi-user computing apparatus, a single user wortetation, or an embedded 
control system. As shown in PIG. 1, computer system 100 comprises a 
processor 110 connected to a main memory 120, a mass storage interface 135 1 
a terminal interface 140, and a network interface 150. These system 
components are interconnected through the use of a system bus 160. Mass 
storage interface 135 is used to connect mass storage devices (such as a 
direct access storage device 155) to computer system 100. One specific 
type of direct access storage device is a floppy disk drive, which inay 
store data to and read data from a floppy diskette 195. 

Main memory 120 contains data 122, an operating system 124, a 
host-based application 125, screen scraping APIs 126« a navigation tool 



127, navigation APIs 131« and a graphical user interface 134. Navigation 
tool 127 includes a portion for flow definition 128 and a portion for 
operation definition 12S. In addition^ navigation APIs 131 inclxide flow 
APIB 132 and operation APIs 133 1 and GUI 134 incltades 001 APIs 135. 
CooHputer system lOO utilizes well known virtual addressing mechanisms that 
allow the programs of computer system 100 to behave as if they only have 
access to a large, single storage entity instead of access to multiple^ 
smaller storage entities such as main memory 120 and DASD device 15S. 
Therefore, while data 122 1 operating system 124 « host*based application 
X2S, screen scraping APIs 126, navigation tool 127« navigation APIs 131, 
and GOT 134 are shown to reside in main memory 120 » those skilled in the 
art will recognize that these prograuns are sot necessarily all coti^letely 
contained in main memory 120 at the same time. It should also be noted 
that the term '^memory*' is used herein to generieally refer to the entire 
virtual memory of computer system 100, Mote that in the preferred 
embodiments of the invention, different parts of vain memory 120 are 
distributed among multiple computer systems on a network. For example, in 
a client/server system similar to system 300 of FIG. 3, con^uter system 100 
would have a server computer system running host-based application 125, 
while a client computer system would have the screen scraping APIs 126, 
navigation tool 127, navigation APIs 131, and GOT 134. 

Processor 11 o may be constructed from one or more microprocessors 
and/or integrated circuits. Processor IIO executes program instructions 
stored in main memory 120. Main memory 120 stores programs and data that 
processor 110 may access. When computer system 100 starts up, processor 
110 initially executes the program Instructions that make up operating 
system 124. Operating system 124 is a sophisticated program that manages 
the resources oC computer system 100. Some of these resotirces are 
processor lio, main memory 120, mass storage interface 135, terminal 
interface 140, network interface ISO, and system bus 160 « 

Data 122 represents any data that serves as input to or output from 
any program in con^ter system 100. Operating system 124 is a multitasking 
operating system known in the industry as 0S/400j Tiowever, those skilled in 
the arc will appreciate that the present invention is not limited to any 
one operating system. 

Host -based application 125 is any software application that formats 
its data input and output for a dumb terminal. A green screen application 
is one suitable example of a host-based application. Screen scraping APIs 



10 



12$ are low- level application prcgrdm interfaces (i.e., progrjsuns) tbat are 
called to get data from and send data to the host-based application 125* 

Graphical user interface 134 is a GUI that is designed to communicate 
with the host -leased application 125 by invoking navigation APIs 131. GOI 
134 suitably includes a number of GUI APIs that provide an architected 
interface for cononmnicating wich GOX 134. this allows the details of the 
screen scraping APIs 126 to be encapsulated within the higher level flow 
APIs 132 and operation APIs 133 ^ thus giving the programmer much higher 
level navigation and operation capabilities without knowing how the screen 
scraping APIs perform cheir functions. This results in a GUI that can be 
ported to different green screen applications with a odnimutn of effort by 
defining navigation APIs for the different green screen application that 
implement the functions called by an existing GDI. 

Navigation tool 127 includes a portion for flow definition 128 and a 
portion for operation definition 129, The navigation tool 127 is a 
software tool that is used by a programmer to enter information relating co 
the navigation of a host-based application. Typically, the programmer 
invokes the main menu on the host-based application » and enters information 
that is displayed on the main menu into the navigation tool 127 to define 
how the application may be navigated. Navigation tool 127 may present a 
graphical user interface that allows the user to define the flow definition 
128 and operation definition 129. In the alternative, tool 127 may read 
one or more script files that describe the flow definition 128 and 
operation definition 129. Of course p there are many other ways for a user 
to define flow definition 128 and operation definition 129. The flow 
definition 128 and operation definition 129 of navigation tool 127 are used 
to generate flow APIs 132 aixd operation APIs 133, respectively. These 
navigation APIs 131 define high level functions that may be invoked by the 
GDI 134 without interacting directly with the screen scraping APIs 126. 

Although computer system 100 is shown to contain only a single 
processor and a single system bus, those skilled in the art will appreciate 
that the present invention may be practiced using a computer system that 
has multiple processors and/or multiple bus^s. In addition, the interfaces 
(called input/output processors in AS/400 ^terminology) that are used in the 
preferred embodiment each include separate , fully programmed 
microprocessors that are used to off 'load compute* intensive processing from 
processor llO. However, those skilled in the art will appreciate that the 



11 



present invention applies equally to computer systems that simply use I/O 
adapters to perform similar functions. 

Terminal interface 140 is used to directly connect one or more 
terminals 155 to computer system 100. These terminals 165, which may be 
non-- intelligent (i.e., dumb) terminals or fully programmaJ^-^le workstations, 
are used to allow system administrators and users to communicate with 
con^ter system 100. Note, however, that t^le terminal interface 140 is 
provided to support communication with one or more terminals 165, computer 
system 100 does not necessarily require a terminal 165« because all needed 
interaction with users and other processes may occur via network interface 
150. 

Network interface 150 is used to connect other cooputer systems 
and/or workstations {e.g., 175 in PIG. i> to computer system loo across a 
network 170. The present invention applies equally no matter how computer 
system 100 may be coimected to other computer systems and/or workstations, 
regardless of whether the network connection 170 is made using present*day 
analog and/or digitaa techniques or via some networking mechanism of the 
future. In addition* many different network protocols can be used to 
implement a network. These protocols are ^ecialized computer programs 
that allow computers to communicate across network 170. TCP/IP 
{Transmission Control Protocol/ Internet Protocol) is an example of a 
suitable network protocol. 

At this point, it is important to note that while the present 
invention has been (and will continue to be) described in the context of a 
fully functional computer system, those skilled in the art vfill appreciate 
that the present invention is capable of being distributed as a program 
product in a variety of forms, and that the present invention applies 
equally regardless of the particular type of signal bearing media used to 
actually carry out the distribution. Bxaaples of suitable signal bearing 
media include: recordable type media such as floppy disks (e.^. , 19S of 
PIG. 1} and CD l^OM, and transmission type media such as digital and analog 
communications links. 

The remainder of this specification describes how navigation tool 127 
is used to generate flow definition 128 and operation definition 129 of 
faost*based application 125, to generate corresponding flow APIs 132 and 
operation APIs 133 that can be invoked by GUI 134. Navigation tool 127 
thiis provides a way to easily generate middleware {e.ff^ « flow APIs 132 and 
operation APIs 133) « t^ich provide much higher level functions to GQI 134 
than those provided by screen scraping APIs 126. As a result, GDI 134 can 
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be more easily ported to a different green screen application by using 
navigation tool 127 to define APIs for the different green screen 
application that are called by GVl 134 . 

Referring now to PIG. S, method €00 shows steps in accordance with 
the preferred embodiments for entering flow definition 128 and operation 
definition 129 into navigation tool 127. First « the main menu (i.e., 
starting menu) of the green screen application is displayed (step $10) on 
one computer system. A user then reads the menu options that the main menu 
presents, and enters information for relevant options into the navigation 
tool (step 620) that is running on a different computer system or in a 
different window on the same cooiputer syistem. Kote that "relevant optiras* 
as xised herein means options that the user wants to enable in the graphical 
user interface. This concept is especially useful in the context of 
web-enabling an existing green screen application. The relevant options 
that are entered in step 620 are those options that the programmer wants to 
web-enable, meaning those that need to be accessible via the world-wide 
web« Many companies have sophisticated green screen applications that 
perform mission-critical functions that should not be accessible to 
outsiders, as well as performing other functions (such as order processing) 
that needs to be accessible via the world-wide web. Navigation tool 127 
allows the user to select which features are relevant^ and should therefore 
be included in the GOT. All options that are not entered into the 
navigation tool 27 will not be accessible via the GUI. Step 620 thus 
provides a way to easily define which options should be enabled in the GOT 
by defining those options in the navigation tool, while all other options 
.will ziot be accessible via the GUI. 

Once all selected options on the main menu are entered into the 
navigation tool, one of the relevant options is selected (step 630) on the 
computer system that is running the green screen application. The result 
is that the next menu is presented to the user. If this menu contains 
relevant options that need to be enabled in the graphical user interface 
(step 640*YES) , method 600 returns to step 620, and steps 620, 630 and 640 
are repeated until all of the relevant options that are to be enabled in 
the graphical user interface are entered into the navigation tool (step 
640allO> . At this point the navigation tool has all the relevant 
information relating to the flow between menus in the green screen 
application, and the user can now define higher level operations (step 650) 
that use the flow information to generate functions that greatly simplify 
the design of the graphical user interface. Once all desired operations 
are defined (step 660«N0) , method 600 is done. At this point the menu 
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Cations entered by the user make iip the flow definition 128 of FIG. 1, and 
the definitions of the operations entered by the user make up the apejratian 
definition 129. Once the navigation tool 127 performs the steps in method 
600 of FIG. €, it then suitably generates the flow APIs 132 and operation 
APIs 133 that may be invoked by graphical user interface 134 (FIG. 1} . 

A sample menu structure 700 for an imagixiary green screen application 
is shown in FIG. 7. Each box corresponds to a screen ie.^., menu display « 
display panel, or data entry panel) in the green screen application* and 
the arrows between boxes illustrate how a user may move betmen menus. The 
main menu 710 includes four options: 1) inventory; 2) work with orders; 3) 
purchasing; and 4) customers. The user selects one of these options by 
pressing the number corresponding to the option and pressing the Enter key. 
When the second option is selected, the work with orders menu 720 is 
displayed to the user. On this menu* the liser can select one of five 
^tions, or may return to the previous menu by pressing the P12 key. 
Selecting the second option ""order processing*" in the work with orders menu 
720 results in displaying the order processing menu 730, which has four 
different options that, may be selected. In addition to the listed options, 
pressing the. P4 key displays the inventory menu 770, pressing the F12 key 
displays the work with orders menu, and pressing the F3 key displays the 
main menu, as shown by the key definitions at the bottom of the order 
processing menu 730. If the order entry option in the order processing 
menu 730 is selected, the order entry menu 740 is then displayed. Order 
entry menu 740 includes four options. In addition, the order processing 
menu can be displayed by pressing the F12 key, and the main menu can be 
displayed by pressing the F3 key* Selecting any of the options on the 
order entry menu 740 would display other menus that are not shown for the 
scJce of sin^licity* The sample menu structure 700 is shown to illustrate 
some of the features of the preferred embodiments of the present invention. 

When the main menu 710 is displayed, selecting the fourth option 
results in displaying the customers menu 750* which provides four options. 
Pressing the F12 key returns to the main menu 710 or the work with orders 
menu 720, depending on which one was the last menu displayed before 
invoicing the customers menu 750. Because the customers menu 750 may be 
displayed from both the main menu 710 and the work with orders menu 720, 
pressing the F12 key to "return* must result in returning to the mexni that 
was displayed just prior to displaying the customers menu 750 « which will 
be one of the menus 710 or 720. When any of cations X, 2, or 4 in the • 
customers menu 750 is selected, another screen (not shown) is displayed to 
perform those functions. For the purpose of illustration, only one of the 



four options are represented in FIG. 7. When the user selects option 3 and 
presses the Enter key, the customer data entry screen 7^0 is displayed, 
which includes data fields for the c\istomer's name^ address, city, state, 
ZIP, and phone number. In addition, the main menu may be displayed by 
pressing F3, and pressing F12 results in returning to the custoners menu 
750 • 

uhen the main menu is di^layed, selecting the first option results 
in displaying the inventory menu 770, which includes five options. In 
addition, when displaying the inventory menu 770^ the main menu may be 
displayed by pressing the F12 key. 

The information in the menu structure 700 of FIG. 7 can be used to 
derive all information needed to ziavigate between menus in the green screen 
application* This navigation information is shoirfn by the menu structure of 
FIG. 8. Each menu is assigned a panel number from PO to ?6. Each menu 
contains three columns that list the display panels (i.e., menus) that can 
be displayed, the key or keys that are pressed to select that panels and 
how many steps away the selected panel is from the current menu. For 
exanq^le, the main menu is assigned a label of PO (panel 0) . The 
information in the columns shows that to reach display panel PI (which 
corresponds to the work with orders menu 720) , option 2 is selected 
followed by pressing the Enter key, and this panel is only one step away. 
Navigating to display panel P2 (which corresponds to the order processing 
menu 730) from the main menu is done by first navigating to display panel 
PI, and then navigating to display panel P2. because there is no direct 
route from the main menu to the order processing menu 730. The entry for 
P2 in PO thus shows the same key sequence as for PI, but that P2 is two 
steps away. In similar fashion, panel P3 (which corresponds to the order 
entry menu 740) can only be visited from the main menu by passing through 
PX and P2. For this reason, the entry in PO for P3 shows the same key 
sequence (i.e.. Opt 2 & Enter) as the Pi and P2 entries, but P3 is three 
steps away. 

The entry for display panel P4 in PO indicates that P4 is visited 
from PO by pressing option 4 and Enter on the main menu, and is one step 
away. Panel PS can only be visited by navigating through P4, so the entry 
for display panel P5 in PO shows the same key strokes as P4. namely Opt 4 & 
Enter, but is two steps away. Finally, the entry for display panel P6 in 
PO shows that navigating to P6 from PO is done by pressing Opt 1 & Enter, 
and is one step away. For each menu, the keys that navigate to other menus 
that are one step away are shorn by arrows leading from the menu* To 
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navigate to menus that are more than one step away, one of the arrows out 
of the menu is taken, which will navigate one step closer to the desired 
menu. Note that the preferred embodiments prefer the shortest path to 
longer paths, so if multiple paths to a menu exist, only the shortest path 
is represented. In some circumstances, there may be multiple shortest 
paths. When this occurs, the selection of one of the shortest paths may be 
random, or may be done according to any suitable selection heuristic. 

Referring xiow to panel PI (7ao) of FIG. 8, when panel Pi (which 
corresponds to the work with orders menu 720 shown is FIG. 7) is selected, 
the user may navigate to the main menu (panel PO) that is only one step 
away by pressing the FX2 key. Panel P2 can be displayed by pressing Opt 2 

Enter « and is only one step away. Kavigating to panel P3 requires 
passing through P2, so the entry for P3 in PI shows the same keys to get to 
panel P2 (namely. Opt 2 & Enter), but P3 is two steps away instead of one. 
Navigating to panel F4 is done by pressing Opt 5 auid Enter, and is one step 
away. Navigating to panel PS and P6 is done by pressing the F12 key« auid 
both of these panels are two steps away (through PO) . 

Panel P2 of FIG. 8 is considered next. Panel P2 corresponds to the 
order processing menu 730 of FIG. 7. To navigate from P2 to P0« the F3 key 
is pressed, and PO is one step away. To navigate from P2 to PI, which is 
one step away, the F12 key is pressed. Navigating to panel P3 is done by 
pressing opt 1 i Enter, and P3 is one step away. Navigating to panel P4 is 
done by pressing F3 (to go through PO) , and is two steps away. Navigating 
to panel PS is done by pressing F12 (to return t:o Pi) , and is three steps 
away. Navigating to panel P6 is done by pressing F4, and is one step away. 

Referring now to panel P3 in FIG. 8 (which corresponds to the Order 
Entry menu 740 of FIG. *7)« to navigate from P3 to PO, the F3 key is 
pressed, and PO is only one step. away. To navigate to PI, the F12 key is 
pr^B^d (to go through P2) , and PI is two steps away. To navigate to P2, 

the F12 key is pressed, and P2 is one step away. To navigate to P4, the F3 
key is pressed, and P4 is two steps away (through PO) • To navigate to PS, 
the F3 key is pressed, and P5 is three steps away (through PO and P4) . To 
navigate to P6, the F3 key is pressed, and P6 is two steps amy (through 
PO) . 

Panel P4 of FIG. B corresponds to the customers menu 750 of FIG. 7. 
Note that pamel P4 in FIG. e contains a column ''Last'' that does not exist 
in any of the other panels. This column is required, because the 
navigation information varies when the F12 key is pressed to return to the 
previous menu depending on the last menu before navigating to P4. in other 
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words, it the user navigates to PI, then to P4 and presses the F12 key, P4 
will return to Pi {the last panel in time that navigated to P4) . If, on 
the other hand, the user navigates to PO then to P4, pressing F12 will 
return to PO from whence it came. Because the F12 key can result in 
navigating to different panels dependixig on which panel was the last in 
time to navigate to panel P4, the ''last* panel information is needed to 
navigation from panel P4. If the last panel was PO, navigation to PO may 
be done by pressing the F12 key, and panel PO is only one step away. If 
the last panel was PO, navigation to PI is done by pressing the F12 key, 
which returns to PO, and PI is two steps away from P4. In similar fashion, 
if the last panel was PO, navigation to panels P2 and P3 is also done by 
pressing the F12 key, with P2 being three steps away and P3 being four 
steps away. Navigation to PS does not depend on the last panel, so the 
entries for PS shows that regardless of whether PO or PI was the last 
panel, navigating from P4 to PS is done by pressing the Opt 3 & Enter keys, 
and P5 is one step away. If the last panel was POt navigating to P$ is 
done by pressing the F12 key, and P6 is two steps away. If the last panel 
was PI, the steps in navigating to PO, PI, P2, P3, and P6 are different 
than the case above, when the last panel was PO . Navigating to each of 
these screen^ from P4 when the last panel was PI is done by pressing the 
F12 key, but the number of steps are different than the number of steps 
when PO was the last panel, because pressix^ F12 results in navigating to 
PI instead of PO. 

Panel PS of FIG. 8 corresponds to the cxjstomer data entry screen 760 
of FIG. 7. }7avigating to panel PO is done by pressing the F3 key, and PO 
is one step away. Navigating to panel PI is done by pressing the F3 key^ 
and PI is two steps away (through PO) . Navigating to panel P2 and P3 are 
done in similar fashion, by pressing the F3 key, with the panel P2 being 
three steps away and the panel P3 being four steps away. Navigating to 
panel P4 is done by pressing the F12 key, and P4 is only one step away. 
Navigating to panel P6 is done by pressing the F3 key, and P6 is two steps 
away. 

Referring again to FIG. 8, panel P6 corresponds to the inventory menu 
770 of FIG. 7. Navigating to panel PO is done by pressing the F12 key, 
which returns to PO which is one step away. Navigating to panels PI and P4 
is done by pressing the 712 key, and PI and P4 are both two steps amy 
(through PO) . Navigating to panel P2 is done by pressing the Opt 3 a Enter 
keys, and P2 is only one step away. Navigating to panel P3 is done by 
pressing the Opt 3 & Enter keys, and P3 is two steps away (through P2) . 
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Navigating to P5 is done by pressing the F12 >;ey« and P5 i« tluree steps 
away. 

The menu structure in FIQ« 7 is a sample menu structure that is 
suitably generated by the navigation tool 127 of PIG. 1 in accordance with 
the preferred embodiments. The information used to this menu structure can 
be entered by a user in a number o£ different ways within the scope of the 
preferred embodiments. In one embodiment of method 600 of PIG. a user 
navigates the green screen application on one system and enters relevant 
options and information into the navigation tool 127 using a graphical user 
interface. Once all relevant options have been entered into the navigation 
tool 127, the graphical user interface for the navigation tool suitably 
produces a graphical menu structure for the green screen application^ 
similar to that shown in FIG. 7. In another embodiment, a user can define 
the navigation of a green screen application in a suitable script language. 
Examples of sample script language definitions for the menus in PIC. 7 are 
shown in FIGS. d«l6. For all the script language definitions in FIQS. 
9-16, the •panel" keyword defines the start of a panel definition. The 
«*destpanel" keyword defines which menus can be reached from this menu and 
the distance (i.e., number of steps) to the destination screen. The 
^ii^ut" keyword is used to set the value of a field on the screen. The 
*executekey keyword is used to specify the key to be pressed to caiise the 
application to take action and move to the next menu« Typically, these are 
function keys or the enter key. The "^distance* is the number of steps to 
the selected menu. 

Referring to FIG. 9, a script language definition for the main menu 
710 is shown. Portion 910 shows that when the destination panel is the 
inventory panel, navigating to the inventory panel is done by entering 
option 1 and pressing enter. Portion 920 shows that when Che destination 
panel is the work with orders panel « navigating to the work %fith orders 
panel is done by entering option 2 and pressing enter. In similar fashion, 
portioxis 930-970 each define how to navigate from the main menu to the 
other destination pcuiels. 

PIGS. 10-16 each show a script language definition for mexuas defined 
in FIG. 7. FIG. 10 defines the navigatim from the work with orders panel 
720 to each of the other panels. In addition, FIG* 10 also shows the 
navigation to each of the relevant options on the work with orders menu, 
even though the menus that correspond to these options are not shown in 
PIG. 7. For example, in the script language definition of the work with 
orders menu 720 in PIG. lO, panels ^Inquiry, ^Reports", and "File 
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Kaintenance'' are defined in the script language even though these menus are 
not e^qpXicitXy sho%m in FIG. 1 for the sake of simplicity. 

FIG. 11 shows a script language description of the order processing 
menu 730. Each of the relevant options in the order processing menu 73 0 
and each of the other menus are includ<^d as destination panels^ with the 
appropriate key strokes and distance to navigate to or towards the 
destination panel. 

PIG. 12 shows a script language description of the order entry menu 
740 of FIG. 7. FIGS. 13 and 14 Show a script language description of the 
customers menu 750 of FIG. 7. PIG. 15 shows a script language description 
of the customer data entry screen 760 of FIG. 7« FIG. 16 shows a script 
language description of the inventory menu 770 of FIG. 7. The script 
language descriptions in FIGS. S-16 could be used by navigation tool 127 to 
define the navigation of the green screen application, as shown in 
graphical form in FIG. 6. 

In the preferred embodiments* once the navigation of the green screen 
application is defined, navigation tool 127 generates one or more flow APIs 
(132 in FIG. 1) that may be invoked to navigate the user interface for the 
green screen application. Once the Clow APXs have been generated, higher 
level operations can also be defined that use the flow APIs 132 to 
accoo^lish a desired task. Referring now to PIG. 17, a menu structure 1400 
similar to the menu structure of FIG. 8 is displayed, but instead of 
showing the navigation information, operations aire defined for each menu. 
For example, in main menu 710 of FIG. 17, the following operations are 
defined: GET_aSER_INFO, ORDER_£NTRY, DBLEXE^ORDER. and CHANGE_OKD£R . Each 
operation definition includes a specification of the key or keys that cause 
the operation to be executed. The work with orders menu 720 defines tbe£.e 
same four operations, but the keys for executing these qperations are 
different than those defined in the main menu 710. The order processing 
menu 730 includes an ORDER^ENTRY operation, a DBLBTE^ORDBR operation, and a 
CHANGE^ORDER operation, with their corresponding keys to invoke these 
operations. The order entry menu 740 defines these same operations, but 
the keys used to invoke the DBLETE^ORPER operation are different than those 
used to invoked the DELETE jORDBR operation in the order processing menu 
790. The customers menu 750 of FIG. 17 defines a GBT_USER_XNFO operaticm, 
and how this operation is emcuted. In similar fashion, the customer data 
entry screen 760 defines a GET_0SBR_IHF0 operation, and how this operation 
is executed. Note that the inventory menu 770 does not have any defined 
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operations. We assume for this example that inventory operations are not 
enabled in the graphical user interface. 

Xn the preferred eioboditnents, once operations are defined (as shovm 
in FIG. 17), navigation tool 127 generates operation APIs (133 of FIG. 1) 
for each defined operation. These operation APIs 133 invoke flow APIs 133 
as needed to navigate the green screen application in performing the 
desired operation. One significant advantage to defining q^erations in 
this manner is that a graphical user interface with different 
characteristics of the green screen application can be defined. For 
example^ a green screen application may be designed to communicate with a 
user by opening a session as each new user logs on, performing the desired 
functions, and closing the session when the user is done. Opening and 
closing sessions in a green screen application are functions that require 
significant system overhead. It may be preferable to open a session* and 
to allow for information from mxiltiple users to be entered into the green 
screen application during a single session. The capability of defining 
operations for each menu thus allows the capabilities of the green screen 
application to be e:qpanded beyond what its native Intearface would allow. 

Similar to navigation, c^rations for a menu can be defined using a 
graphical user interface to navigation tool 127, can be defined in a 
suitable script language, or can be defined in any other suitable manner. 
FIGS. 18-20 show sxiitable script language for the GET_U$BR_INFO operation 
shown in FIG, 17. Referring to PIG. 18. the operation GET_OSER_INPO" for 
the main menu is defined. This qperation is executed by pressing the Opt 4 
& Enter keys. Referring to FIG. 19, a GET_DSER_IHFO operation on the 
Customers menu is performed by putting the va^ue in the customerlD field of 
the green screen application in the custID field of the client field (i.e., 
GUI) . Once the customer ID is entered, option 3 is selected, and the Enter 
key is pressed. Referring to FIG, 20, a GET_OSER_lOTO operation on the 
customer data panel is performed by placing the customer's name stored in 
the cxistname field of the green screen application in the '^name'' field of 
the GUI; by placing the first part of the customer's address in the 
custadrl field of the green screen application in the •addressl" field of 
the GUI; by placing the second part of the customer's address in the 
custadr2 field of the green screen application in the •address2'' field of 
the GUI; by placing the customer's city in the custcity field of the green 
screen application in the *city field of the GUI; by placing the 
customer's state in the custstate field of the green screen a|H?lication in 
the "state" field of the GUI; by placing the customer's ZIP code in the zip 
field of the green screen application in the ^sip* field of the GUI; by 
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placing the customer's phone number in the custphone field ot the green 
screen application in the •phone" field of the GOl; and by executing the P3 
key to move back to the main menu 710, One suitable way for placing data 
in fields in the GUI is to invoke GUI APIs 135 within the GET_USER_INFO 
5 operation. However, there are other ways within the scope of the preferred 

embodiments for perf oming operations and exchanging data with the GUI . 
For example, instead of putting the interaction with GUI APIs 135 within 
the GBT_USER_1NP0 operation^ the GUI itself could perform the GBT_OSBR_^INFO 
aeration, which retrieves the data, and the GUI could then perform 
10 e^licit functions (such as calls to GUI APIs and/or additional APIs) to 

move the retrieved data into the GUI. This an other variations for 
comimini eating between the GUI and the green screen application are 
expressly within the scope of the preferred embodiments. 

The embodiments described herein disclose an apparatus, method, and 

15 program product that define one or more navigation APIs that can be called 

to navigate a software application. In the preferred embodiments, a 
graphical user interface is defined that calls these APIs, thus allowing 
the GUI to rely on higher level functions that are independent of any 
particular green screen application. The present invention is especially 

20 useful when web-enabling a green screen application. Operation APIs define 

the highest level functions that may be called by the GUI, These APIs in 
turn call flow APIs that define the flow in the green screen application. 
The operation and flow APIs can both invoke screen scraping APIs to 
communicate with the green screen application. By providing this 

25 ""middleware' that provides another level of abstraction between the screen 

scraping APIs and a GUI. the programmer of the GUI need not have any 
information regarding the specific screen scraping APIs that are used to 
access the green screen application. Instead, access to the screen 
scraping APIs is preferably encapsulated by invoking only operation APIs 

30 and flow APIs in the GUI, which in turn may access screen scraping APIs as 

appropriate. As a result, a GUI that is designed to call the navigation 
APIs of the present invention can easily be ported, to a different green 
screen application by using navigation tool 127 to generate flow APIs and 
operation APIs that are called by the existing GUI. 
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1. A coo^uter system comprising: 
/ at least one processor; 
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5 a memory coupled to the at least one processor; 

a navigation tool residing in the memory for execution by the at 
least one processor, the navigation tool receiving flow definition for a 
software application from a user and generating therefrom at least one 
application program interface (API) for navigating the software 
10 application. 

2. The system of claim i wherein the software application comprises a 
host -based application. 

X5 3. The system of claim 1 wherein the navigation tool further receives 

aeration definition for the software application from the user and 
generates therefrom at least one API. 

4. The system of claim 1 wherein the flow definition is defined using a 
20 graphical user interface. 

5. The system o£ claim 1 wherein the flow definition is defined in a 
script language. 

25 .6. The system of claim 1 wherein the at least one API comprises at least 

one flow API that at least partially defines flow of the software 
appl i cat ion « 

7. The system of claim 1 wherein the at least one API comprises at least 
30 one operation API that defines at least one operatic that is performed by 

interacting mth the software application* 

8. The system of claim 1 further comprising a plurality of screen 
scraping application program interfaces (APIs) residing in the memory, 

35 wherein the at least one API for navigating the software application 

invokes at least oxiB of the screen scraping APIs. 

9. A method for providing a plurality of application prograxn interfaces 
(APIs) that may be called by a graphical user interface (GUI) to navigate a 

40 software application, the method conqprising the steps of: 

(1} invoking a display panel in the software application; 
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<2) entering information about the display panel into a navigation 

tool ; 

(3) repeating steps <1) and <2) until all desired information 
relating to the software application has been entered into the navigation 
tool; and 

(4) the navigation tool generating from ihe information entered in 
step (2) the plurality of APIs. 

10. A method for providing a graphical user interface for a software 
application^ the method comprising the steps of: 

a user entering flow information for the software application into a 
navigation tool; and 

the navigation tool generating from the flow information at least one 
application program interface (API) that is called by the graphical user 
interface to navigate the software application. 

11. A program product comprising: 

(A) a navigation tool that receives flow definition for a software 
application from a user and generates therefrom at least one application 
program interface (API) for navigating the software application; and 

(B) signal hearing media hearing the navigation tool. 
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